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INTRUDUCTIUM 



A. hlSlORY OF THE FOPTRAM LANGUAGE 

FUHlRAi^j was produced tHe late lR50*s for use on IbN* 
computers* With the backino of IBMf FORTRAN became wiaely 
accepted and was subsequently oevelopeo for many machines 
ourinq the 196U*s. The AfT^ppican iNational Stan darns 
Committee specification of FOPIRATt in l°o6 f21 has araouallv 
become accepted and most present compilers conform to this 
Stan care. 

in 1976 the committee developed a craft proposed 
^American National Standara FORTRAN l^J as a replacement for 
the original Standarc. The FORTRAN lanauage definition 
aescribed in the proposed Standara included essentially all 
features of the original Standara with the major exception 
being the removal of the Hollerith data type. A numcer of 
adaitional capabilities including a character data type and 
file oriented input/output were also added to the lanauage. 

FORTRAN has made a significant contribution to computer 
technology. its development provided a language that was 
easily learned by a wiae variety of people arc that was 
available for use on existing haraware. oy provicinc a 
packed statement form which aid not rely on the presence of 
blanks^ hORTRAN allowed more efficient storage of proarams 
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and greater ease of programming 



AMtn tne use of the 



equivalence statementf tHe control of storage allocation uv 
the programmer was permitted for the first time* f.9] 



Since 


its 0 r i a i na 1 


de f i n i r i on 


/ FORTRAN has become 


the 


St andard 


scientific 


computer 1 


anauage. oecause 


o t 


the 


portability of proqra'i-s written 


in FGRTRA^J it 


has 


a 1 sc 


become a 


common i 


ntermediate 


1 amguaqe that 


has 


been 


generatea 


oy language 


processors 


and compilers/ as 


well 


as 



one of tne standard lanauages for proaram portability. 



d. THE Ubt OF FURI^AN aITH M I C PUC U T E R OYSTt^^S 



Recent advances in the construction of dioital circuits 
have resulted in tne availability of low-cost LSI computer 
components. Ihese components/ wnich include central 
processing units/ memory systems and peripherals for 
input/outoutf can be comoined to form a digital computer 
known as a microcomputer. A large number of application 
areas for microcomputers have been identified/ such as 
intelligent terminals/ dedicated processors ana minicomputer 
control tasks, fill 



In contrast to the advanced technology utilised in 
microcomputer hardware/ the software designeo to support 
microcomputers has been slow in develop ina. A great deal of 
applications work has been done directly in machine language 
since microcomputer confi durations have often lackecj the 
memory and inout/output capacity to support program 
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development in assembly 1 anquage 



Ihe use of assembly 



language has oeen supported b/ many m i c roc omnu t e r s and r.hen 
combined witn a text editor and debugging aids formed a 
useful package for the proarammer. To date^ very few hiqn- 
level languages nave been developed for use on a 
microcomputer system. PLM [g] is currently the only hian- 
level microcomputer systems programming languace which is 
widely used . 

^ith the expanding number of acolications for 
microcomputers/ high-level lanquaaes must assume an 
i'^creasinalv important role in the development of software 
for use on microcomputer systems. An i mole mentation ^ne 
hORfhAi'j 1 anauage coulo be a valuable audition to the nian- 
level languages that can be utili2eo for microcom cuter 
software sudoc r t , 

The purpose of this paper is to describe the desicn and 
implementation of an LALRCl) FORTRAf^i gramm ar for use ^ith a 
self-hostea compiler. An overall system design to suoport 
the FORTRAN lanauage on a microcomputer system is also 
aescrioed. 

C. MOTIVATIUM FUR Au LAlR(1) GPA^^MAR 

One of the major techniques used in current compiler 
construction is cased on wor< done by Knuth I8j/ wno 
developed deterministic parsing algorithms for the left-to- 
right translation of languaqes defined by LR(k) grammars. A 



grammar is LR(k) if each sentence it generates can be parsed 
from left to riaht in a single scan with at most k loo<anead 
symDo 1 s • 

LK(k) grammars have several advantages. They arp 
unamoiguous. Construction alaorithms exist for this class 
of grammar tnat can buila parse action tables. A parser can 
use the tables produced bv the analyzer to aetermine if 
language statements defined oy the grammar are well-formed. 

LK(k) grammars always reouire a lookaheaa of < symbols 
for the parser to determine the next state. LaLk(<) 
grammars differ from lr^(<) in that the loo<anead is only 
performed when necessary / thus producing much smaller parse 
taoles. Ihe largest class of currently implementacle ( <) 
grammars are LALR(l), 

An efficient parser can oe written to interpret parse 
action tables for LALR(l) grammars fll. The parser is a 
table-ariven pushdown automaton that assumes a seauence of 
states (shift/ reduce/ accept/ or error) while scanninc tne 
input. Decisions are based on the next input symbol and 
information accumulated on a parse stack. The final state 
inai cates whether the input was well-formed. 

The availability of such an LALR Parser Generator llu] 
for use in developing a FORTRAfsi grammar was the major factor 
in determining the method of constructing a compiler for use 
in the implementation of the FORTRAN language on a 



microcomputer system 



The LALR Parser program accepts a 



Backus iMaur Form (BNF) grammar definition as inputi ana tne 
number of lookaHeads allowed/ anti aetermines if the grammar 
is amoiguous. If the grammar is acceptaole then oarse 
tables are proaucea that can be usea with a parser, and 
syntactic and semantic analyzer routines, to provide the 
basis for the systematic construction of a compiler. The 
parse tables that are produced are compatiole with tne PL-'^ 
proqrammina 1 ancuage but can be modified for use witn other 
1 anquage s . 

The LALk Parser Generator ^as instrumental in tne 
aevelopment of the larg^ ora rn mar necessarv for FuPI^'Ah since 
oNF aetinitions could ce testea and dehuqgeo incrementally 
as the grammar was developed. 
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grammar SPtClFICATIOfvJ AND DESIGN 



11 . 

A. INTKUUuCnON 

[his chaoter describes the reauirements^ goals# and the 
design decisions considered during the aevelopnnent of the 
LAlRCIJ FCJRTRAh^ graT»rnar. in addition# suaoested extensions 
to tne aramnar are included. 

[he final t^o pass version of the LALP(l) FUPF^A^i 
gra^rirr. ar is containec in Aopendices A and B. The sy'^tax of 
the FUkIkaN statements that this cramoar defines is included 
in the l97o draft proposed American National Standard 
FOkIKA)*'^. The few deviations from the oroDOsed Standard are 
noted in the ** Statement Restrictions" section in this 
chapter. 

B. grammar specification 

The syntax of inaivioual FORTRAN statements and their 
correct ordering within program units described in tne 
proposed Standard were used to form the basis of tne grammar 
design. it should oe noted that the grammar developed to 
define the proposed Standard also syntactically defines the 
19bb AidSI Standard FORTRAN. Not considerpd in tne design of 
the grammar were language extensions that have been mace to 



ANSI Standard FOKTRAInj t>y language orocessorSf unless they 
have been included in the proposed Standard. 



c. grammar design 



FURIRAN as described in Refs. 2 ana U has been 
considered an inherently ambiguous lannuage. In orcer to 
completely define the syntax of the language an arrhioucus 
grammar is requirec. Since LALR(l) grammars must oe 
unamoiguous by definition^ this incomoatibility created 
problems during the oevelooment of the grammar. 



in tne nesion of tne n ram mar two aonroacnes v/ere ta'^^en 
in order to solve these oroblems. tirst/ consiaeration was 
given to exoanaina the grammar to define more than the 
syntax allowed hen comoensating actions could oe pertormed 
in the semantics of a compiler implementing the grammar. 
Secondf if that approach failed then tne grammar WciS 
restricted to define only a suDset of the syntax of tne 
language. 



1 . Des i gn Goals 

The design aoals for the LALR(l) FORTRAN grammar 
were: (IJ to adhere as closely as possible to the proposed 
AMS Standard requirements of the FORTRAN language 
definition^ (2) to maintain overall simplicity in tne 



grammar and (3) to develop a crammar small enouan to he 



utilized in a self-hostec compiler for a m i c r oc crrpu r e r 



system with 16K bytes of memory. 

<2 • Tokens 

The tokens in the initial grammar desian consisted 
of special characters^ reserved words^ an ioentifierf a 
statement laoel^ a format incut# and character# integer# 
real and douole crecision constants. As the arammar was 
aevelopeo it was necessary to create statement termination# 
array identifier# exponentiation ooerator and cone a t ena t i on 
operator tokens in orcer to resolve amoiguities. 

a . deserved o r j s 

in order to recognize F0r:TnAi\ >^ey words# such as 
DIF'tNSiUN# CON* MON# PtAU# etc.# the use of reserved woras was 
required in the lanquage definition. in the Ai\Si and 
proposed AMS Standara FOPTPAM key words were not reserved 
and could also be useo as identifiers. However# in order to 
conform to normal grammar technidues reserved wore to«.ens 
were created to distinguish them from identifiers. In 
addition to the FGRTRAM <ey words the logical constants 
.TRUt. and .FALSE.# the relational operators .EQ.# .TjE.# 
.GE.# .Gl.# .LE. and .Lf.# and the logical operators .AnD.# 

.MOl.# and .OR. were included as reserved words for ease in 
later implementation of the grammar. 
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Statennent fermination 



The FOHTRAfsj lanouage does not have a special 
”end-ot-statement” delimiter equivalent to the oerioo in 

COBOL or the semicolon in ALGOL. ThuSr in order to 

terminate each statement definition in t^e gram nr. ar an ”ena- 
of-statement” token v^<as created. vn’thout this tokens the 
LALH Parser Generator was unable to differentiate between 
individual statements in th*=» lanouage. The use of this 

token must oe imolemented in any com oiler tha*t utilwes the 
grammar out shouUj he transparent to the us^r or tne 

c omo i 1 e r . 



c. Statement Labels 

The special to<en “statem<=^nt label" was used to 
define the statement laoels oiven to specific statements. 
However^ references to statement labels within a statement 
ie.g./ GO TO 10) were oefinea as integer constants. 

d. Special Characters 



Durina the development of the qrarr. mar the 
initial set of special characters caused ambiguities in the 
definition of an expression. The differences in the use of 
the multiplication operator * ana the exponentiation 
operator ** could not be resolved. A similar problem was 
encountered with the civide operator / and the concatenation 
operator //. it became necessary to create additional 



tokens for the exponentiation operator and the concatenation 



ooe r a t o r . 



e. Format I nou t 



The "format input" token ^as inclu Oea in the 
grammar design to allow format statements to be handlea in 
the semantics of a compiler implementino the orammarr rather 
than in the grammar, 

f • ir^ead Pa ren 



A major problem was encountered in aeveloping 
the Grammar to o^fine the FuPTRAN ^eao state T.en^* Tne 
syntax of the unformatted r'=»ad state m, ent ^ as ( <co'^trol 

information list> )f while the syntax of the formatted read 
statement was kEAD <format>. v'nth both the format ana the 
control information list allowed to he an expression/ a 
description of the syntax of the two read statements ppcam® 
kEAL) ( <expression> ) and READ <expression>. Since tne 
expression syntax included a rule that stated <excression> 
( <expression> ) there was no way for an LALR(l) Grammar 
to un amb 1 quous I V define Doth tyoes of read statement. To 
solve this problem a "read paren" token ^ as created to 
define the beginning of an unformatted read statement. 
Although it is syntactically correct to parenthesize the 
format in the formatted read/ in utilizina the grammar the 



design imposes the recuirement tnat a parenthesis following 



the KtAu automatically 



indicates an 



unformat tea 



read 



statement • 

g. Identifiers and Array identifiers 

Identifiers were initially designea to be any 
sequence of one to six letters or numbers Deginninq with a 
letter^ which was not a reserved wora. however^ a oroolem 
was encounterea in differentiatina between function 
references and array element references. The syntax of Doth 
as defined in tne proposed otanaard consists of cjn 
identifier followeo t;y a oarenthesized list of exoressiomSf 
for example ^ i o , ^ , c) anj ^’AX(6f3/2j. Thus/ in oroer to 
resolve this oroolem an array identifier tol^en was createc. 

Jistinguishina bet>/een loentifiers ana arroy 
identifiers remains a nontrivial problem and must be hanoled 
in the semantics. Oeoenaina on the technique usea it mav 
impose the reauirement that arrays cannot be referenced 
prior to their definition in a dimension statement. 

3 « Expressions 

The initial Grammar design included the FORTRAN 
arithmetic/ character and loaical expressions as separate 
entities. These expressions are each constructea usina 
identical operands • loentifiers/ array element refer^^nces 
ana function references. The specific tyoe of each operand 
(character/ intener, etc.) must be examined in oroer to 
determine whether it is valid for use in a particular 



expression. The use of these identical operands again 
caused the grammar to be ambiauous. The solution y^as to 
oefine one General expression for overall use in the FORTPAM 
grammar. The rules that were develooed for this expression 
aefinition enforce operator precedence for eacn fyoe. The 
semantics of a compiler that uses stjch a gramimar must be 
responsiole for oetermining what soecific type of expression 
is oeing useo^ and whether the operands are valio within 
that type of exoression. 

Another oroclem encountered in the expression 
definition was in enforcinc par^^ntnesized expressions as 
reauireo in some FOkTRA >'j statements. syntax of 

expression includec the rule <expression> 

(<expression>). This resulted in the reduction ct a 
parenthesized exoression to an expression prior to its use 
in a statement. In oraer to enforce a oarentnesized 
expression the rule was modified as follows: 

<expression> <oaren express ion> 

<paren express ion> ( <exoression> ) 

The second rule coula then be used in any statements where 
parenthesized expressions were reauireo. 

^ . Complex Constants 

A further example that illustrates the problems 
encountered in constructing an LALR(l) grammar is the 



definition reauireo for a complex 



const ant 



Syntactically a 



complex constant was defined as ( <real constant> t <real 
constant> ). However, this definition coula not be useo in 
the grammar. Examination of the followinq grammar rules is 
necessary in order to understand tne oroblem: 

<comp)ex constant> ( <real constant> f 

< rea 1 cons t ant > ) 

<return statement> RETURN <expression> 

<e^pression> <constant> 

1 <caren expression> 

<oaren expressicn> x d r e s s i on > ) 

<constant> <real constant> 

cased on ^nese Grammar rules the heGinninc of one 
aerivation for the return statement was RETUR^♦ C <rea) 
constant>. Durino the oarsino of this statement with a left 
parenthesis and real constant on the stack tne LALR Parser 
could not determine if the real constant shoula be reduced 
to a constant for eventual use in the return statement, or 
whether to stack a comma for eventual use in a complex 

cons t an t . 

In attempting to overcome the oroblem several 

alternative rules were examined for the comolex constant 

definition that produced similar ambiguous results. The 

final unambiguous definition was as follows: 

<comDlex constant> <complex heaa> <expression> ) 

<complex head> t <exnression> , 

These rules reouire the semantics to aetermire if the 
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expressions in the corrplex constant definition are in fact 



real constants. 

^ • Inout/OutPut Speci ficat ion 

Ihe syntax of the FUPTRAh input/outout statements 
included a large number of input/outout specifications 
associated with each statements including unit numberss 
error specifiers and file soecifiers. The ordering of these 
soecifers and the soecific inout/output specifications 
allov^ed with each statement were initially included in the 
grammar design. How ever/ aue to the large numoer of grammar 
rules required to enforce this syntax a general inout/cutout 
specification replacec tnem in tne final qrarr.mar. This 
requires the interoretation of specific input/outout 
soecifiers for the inout/output statements in the semantics. 

^ • Statement Restrictions 

The grammar for the individual FuRIPAN statements 
was originally desicnea to strictly enforce the syntax of 
the statements in the proposed Standard. uurinq tne 
development of the grammar it was decioea in several cases 
to define only a subset of the syntax in the grammar in 
order to decrease the numoer of rules. Both the common and 
data statement syntax enforced by the grammar allow only one 



name 1 i s t . 


optional 


commas 


for 


the 


go t o / type and go 


statements 


were also 


exc 1 uaed 


f r om 


tne 


Grammar developed. 
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The implicit statement ooseri a special problem which 



was never entirely resolved. The length specification in 
the character implicit statement can be an expression ana is 
defineo oy tne follow i no syntax: 

<implicit statement> ::= I^^PLICIT CH/^KACTtR 
^ <exoression> ( <letter ranoe list> ) 

The combination of an expression and a left oarenthesis 
caused ambiguities in the grammar that coulo not* be 
eliminated. The eventual solution was to restrict the 
syntax for the character lengtn to an integer constant, 

7, Uotional Statement Desicn 





if r eou i 


reo for semantic 


analysis/ many 


0 f 


tne 


g r amma r 


rules i 


n Aopenoices A and 


B that define 


the 


F (J P T P A f'i 


statements could 


be restructured 


and the overa 


1 1 


F D R 1 P A M 


grammar 


would 


still meet the 


requirements of 


an 


L A L K ( 1 ) 


grammar. 


These 


alternate statement definitions 


m 


1 ah t 


oe 



useful in semantic code generation. 



A simple example of this is illustratea by tne 
following two alternate definitions available for th^ 
dimension statement: 

<dimension stmt> DIMENSION <array declaration> 

! <dimension stmt> # 

<array declaration> 

<aimension stmt> ::= <dimen heaa> <array aeclaration> 
<aimen head> DIMENSION 

1 <dimen head> <array aeclaration> # 






The first definition was chosen for use in the final 



grammar because it required fewer rules. The second set of 
rules may be desired for a compiler utilizing the grammar in 
order to determine when the last array declaration is beinq 
processed* 

6 . Splitting the Grammar 

The original LALR(l) Grammar was desianeo to aefine 
the syntax of all the statements in the FURTRAfi languaae. 
The initial grammar aefinition that was oevelopea contained 
approximately 13 ^ rules. The taoles aeneratea h/ t^e L^LR 
Parser for this grammar too‘< over 11 K cytes or re'^ory. 
Ihese tables were much too large to be implementecj in a 
self-hosteo compiler for a loK microcomputer system with a 
4K operating system. Consequently the grammar was split 
into two sections. The first section contained the rules 
for the data and environment definition statements incluoing 
programf subroutine^ function^ block oataf format/ entry, 
data/ specification and statement function statements. The 
second section contained the rules aefinina the format/ 
entry^ data and executable statements. 

Splitting the grammar in this manner had two 
advantages. The larce table size was reduced to 38 UO bytes 
for section one and 4200 bytes for section two. The split 
grammar made it necessary to split fhe compiler into 
separate programs for each section; thus different semantic 
actions associated with identical grammar rules could oe 
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varied within the seoarate programs. For example^ a 
reference to an array element could be nandlea in a 
different manner in each of the proarams. 

A significant disadvantage of solitting the grammar 



was the difficulty imposed in the desian of a compiler that 
utilizes the grammar to process more than one program unit. 



• 


The two grammars 


were 


designed 


so 


that they 


c o 1 d 


eas i i y 


be combined for use in 


a c o m D i 1 


e r 


that ocerated 


in an 


environment where memory 


size 


was not 


as 


restPictea. 





U. AUb'^b'\T A i lOd 
1 . Overview 

fhe initial grammar design included rules defining 
the relationsnips among urogram un^^Sf enforcina statement 
order and defining tne statements allowed within the orogram, 
units. These rules were subsea uently aroopeo primarily to 
reduce the size of the parse tables. In an environment 
where the size of the compiler is not critical these rules 
would provide a useful extension to the grammar. 

^ • Program Units 

The program units defined oy the FUFTRAM lanauage 
are the main orogramf and the function, subroutine and block 
data subproarams. A FURTRAM program must have no rt'ore than 
one main program and can have any number of additional 
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subprograms. Further^ these program units can be in any 
order. Ihe LALR(l) grammar rules that were developed to 
enforce these relationships are as follows: 

<program> <proqram unit> 

! <subprogram> 

I <suborogram> <program unit> 

<proarani unit> <main proqram> 

1 <program unit> <suoorograr unit> 
<suDorogram> <subproaram unit> 

1 <3ubproarafn> <suCDrogram unit> 
<suproqram unit> <f unction suDprogr6m> 

1 <subrou»'ine sutorcgram> 

! <plocl< data 3ubcroqram> 

These oroductions coulo oe of value if more than on^ program 
unit is to be comoilec at the same time, 

3 * Statement Uroerina 

Several versions of an LALR(1) gramrr, ar were 
aevelopea to enforce statement ordering within program units 
ana the types of statements permitted in each program unit. 
An LALK(l) gramm. ar that met these requirements is presented 
in Appendix C. The parse tables generated for the Grammar 
in Appendix C took approximately 2200 bytes of memory. 

These rules could oe included in a compiler that 
implements the grammar if the memory space reouired is 
avaiiaole. An alternative would be to substitute the 
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tne aesign 



aoprooriate semantic actions as 
of the compiler presented later 



is described in 
in this pacer. 



Ill 



SYSTLM ObSlGN 



A. OVtKVlEW 

The system desian recommended for implementation of tne 
FORIRAN language on a microcomputer consists of three 
subsystems: a FORTRAN compiler that generates a relocatable 
intermediate lanouage module for eacn pronram unit (main 
program^ subroutines/ functions/ or block data) in the 
FOKiRAfj source file/ a loader that lin<s the rroaules t^at 
nave been qeneracea Ov tne CQf^Piler/ and an interpreter t^of 
executes the intermediate lancuage. 

The system that is described is designed to execute on 
the Intel 8080 m i c rocompu t e r with 1 oK bytes of memory under 
the CR/I^ (31 operatinc system. CP/M is a monitor control 
oroara!T> that provices a number of basic input/outout 
functions/ a console command orocessor/ ana a comprehensive 
file management packaoe for use with a file system. Tne 
file system is maintained on diskettes (flopoy oisks) which 
contain 856K bytes of storage. This operating system also 
supports a text editor/ a dynamic debugger ana the Intel 
608 U assembler. CH/iM takes bytes of memory; therefore 
the system desian ciscussed for tne implementation of 
FORIRAN has 12K bytes of memory available. The use of LP/M 
or an eauivalent system on the 8080 microcom. outer directly 
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affected the desian r equ i r erren t s 



ana 



recommendatiof^s made 



for the implementation of FORTRAN. 

8. COMPILER 

I • Organization 

Splitting the grammar into two sections^ as noted 
previously/ had a direct impact on the compiler aesign. Tne 
compiler was originally envisioned as one program with 
provisions for multiple passes. Tne imolementatior'i of thp 
split hURIRAN grammar required a separate proarafn for each 
grammar and a control program ^hat provided linKage bttvjeen 
the two programs . 

To execute tne compiler the user of the system wculcJ 
invo<e the control prooram/ and pass the name of the source 
file to oe compilea in the command line as a parameter to 
the program. [he control proaram would then manage tne 
interfaces necessary between tne pass I and pass 2 compiler 
proarams required in the compilation process. The final 
output would be a file containing the intermediate language 
generated by the compiler. 

The system is designed so that the control program 
resides in memory durina the entire compilation. Ihe symbol 
table area is left in m.emory for use by the pass 2 program 
after the pass 1 procram nas completed execution. The pass 
2 program overlays tne pass 1 proaram when read into memory 
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Dv the control program. The memory configuration tor 
implementation of this design is presented in higure 1. 



COMPILER MEMORY ORGANIZATION 
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System Information 



Figure 1 



the 
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This section Giscusses the functions/ the aesign 
requirements ana recommendations for the control program/ 
the pass 1 and pass c? proarams/ and the interfaces reuuired 
among them necessary to implement the FURIAN compiler based 
on the LALR(l) F0R^RA^J arammar, 

^ • Control Program 

The main ouroose ot the control program is to 
control the overall compilation process. In order to 
accomplish tnis it must perform two Dasic functions: M) tne 
loaning of the pass 1 ano pass R proorams and tn^ 
^^^t^al^^ation of their executiori/ and fR) the rn^intenance 
of common informa^'icn such as compiler togoles ana symbol 
taole necessary to both passes. This reauires that tne 
control proaram remain in me^^ory curing the entir^^ 
compilation. 

The Dulic of the executaole code for the control 
proaram resides in memory just oelovw the CP/M opera tin a 
systemi (see Figure Ij. Upon initiation of the program pv 
the user/ execution beains at lOO hex (lOGHJ and an 
immediate jump is performed to the first executaole byte of 
coae located in the upper part of memory. 



The first task the control program must perform is 
to decide »^hether it is being invokea from either the pass I 
or pass 2 program or at the initiation of the FORTPAfj 
compiler. The appropriate actions can then be provided 
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based on this decision. A control ^lag which can be altered 
by the pass 1 and pass 2 programs can be useo to implement 
this reauirement. 

/Jhen t^e control procram is executed for tne 
initialization of a compilation it should perform the 
following functions: (1) initialize its '’scratcn pao" area 
for use by the oass 1 and pass 2 orogramsr id) save trie 
file control block for the FORTPAT' source file and open tne 
file for inout/ (3) maintain the tile control block for tne 
intermediate languaae file and open it for output, (m) 
initialize the sy'^col table area# (5) read t^e executable 
iCuT-^J tile for the oass 1 procram into me'^ory becinninc at 
lOOh, ana (o) jtjmo ♦'o lOOH to transfer control to the pass 
1 p r og r am . 

vjhen the control procram is invoxec at tne 
completion of the pass 1 program it should cneck for a fatal 
error in the oass 1 phase of compilation whicn would 
terminate execution. If none is founds the COM file for tne 
pass 2 program can be read into memory anc control 
transfered to lOOH to begin execution of tne oass 2 procram. 

vVhen the control program is executed via a transfer 
from the pass 2 program it snould again check for a fatal 
error in the Pass 2 phase of compilation ana terminate 
execution if necessary. It must also aeterm. ine if another 
program unit is to be compiled. If an additional program 
unit is to be compilea the control program must reinitialize 
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the symbol table and "scratch pad" area/ with the exception 



of compiler togqleS/ and reloao ana transfer control bac^^ to 
the pass I orogram to continue the compilation process. If 
no more program units are present on the source filer the 
control program must close the FORTRAN source file ana tne 
intermediate language file and return control to the CP/^^ 
operating system. 
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must D e me 


intained for both 


flies in 


0 r 0 p r to 


determine the correct 


r eco rd to oe 
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i n f 0 r me t 


ion required by the pass 1 
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i. 


Pass 1 Prooraf^ 











The pass 1 program implements the grammar presented 
in Appendix A. This procram processes the FoR^RA^j 
statements up to (out not including) the first executable 
statement. Routines for syntactic ana semantic anaivsisr 
symbol table man i ou 1 a t i on r and a parser must be included in 
the program. This section discusses the design requirements 



ifrpcseo by the FORTRAN grammar and some additional ciesign 
considerations necessary for implementation of the program. 
The parser and scanner descrioea in this section were 
implemented and testec. 

a . Pa r se r 

[he parser that was adooteu for use with tne 
pass 1 orogram is based on the oarse action generation 
algorithms used to analyze L. ALR(l) grammars. 

The parser controls the execution of the oass 1 
proaram. It receives a series of tokens from the scanner 
ana analyzes tnem to cetermine if they form a valic^ s^nte»^cn 
in the hURTRAi'j grammar. It bases this decision on the next 
input to<en ana information previouslv accumulated on a 
parse stack where the parser states are maintained. 

The basic actions oer formed ov the parser 
include a shift action that reads a new toxen ana pushes tne 
previous state onto the stac<^ a reduce state that poos tne 
number of elements equal to the handle of the production and 
outs a new state on the stack/ an accept state that 
indicates tne input conforms to the grammar/ ana an error 
state that indicates wnen a syntax error has occurec. 
Additional stac<s can be usea in oarallel with the oarse 
stack that relate to tne translation of the procram/ such as 
pointers into the s/mpol table and temoorary values used in 
r educ t i ons . 
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In order to stoo the execution of the pass 1 



program the grammar allows the parser to proceea until it 
has analyzed an end statement/ wnen no executable statements 
are found in the crogram unit/ until it has analyzed the 
reserved word in the first executable statement/ sucn as OO 
or kEAD/ or until an assignment statement is recoqnizea. in 
the case of the assignment statement/ where no reservea word 
IS contained in the statement (^.g./ A = , it parses to 
the eaual sign. The information previously scanned for tnn 
executable statement must be saved for use by the pass P 
program to oroviae i n i t i a 1 i z a t i on of tne scanner and to 
allo*^ i or any se'^antic actions that need to be performevj. 
by maintainina a stacx that always contains the last three 
tokens orocessecj/ this information can then be pro video to 
the pass d program via tne scratch paa” im the control 
program • 



b . Scanner 

Ihe function of the scanner is to provide tne 
tokens definea in the FORTf^AN grammar to the parser. Thes« 
tokens include reservea words/ special characters/ the 
exponentiation and concatenation operators/ statement 
labels/ identifiers/ array identifiers/ ’’format inputs”/ 
”end-of-statements”/ and integer/ real/ character/ ana 
double precision constants. The scanner that was 
implemented in the pass 1 program encountered no special 
problems in recognizing these tokens with the exception of 
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identifiers/ array identifiers and the *'end-of-statement 
token* 



identifiers and array identifiers noth have the 
same structure. They are a sequence of one to six letters 
or digits that begin with a letter. In oruer to 
differentiate between them/ it was necessary to include 
interaction with the semantics necessaf'y for processing 
dimension statements. i/'<hen the reserved /word DIN'c^JSlUM was 
encounterea a f 1 ao was set to indicate that a to<en of this 
form followed Dy a left parenthesis ^as an array iaentifier. 
This flag was checked bv scanner folic wind the initial 
test for reserve (j woros. If the flag .-was not set^ ^he 
symbol was looked up in the symbol table to determine 1 “^ it 
was an array identifier defined in a previous dimension 
statement. If these tests failed/ the token was assumed to 
be an identifer. The use of this tecnniaue imoosen the 
requirement tnat arrays could not be referenced in any 
FOKIRAN statement prior to their declaration in a dimension 
statement . 



The recognition of the end of a FURfRA'^Ni 
statement by the LALR(l) grammar implementation recuirea an 
”end‘-of‘-statement’* token transparent to the user. A 
lookahead feature was used in the scanner to help determine 
whether the next line was a continuation of the previous 
statement. Since normal hORTKAN card conventions w^re 
maintained/ the decision could be based on a line position 
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pointer that maintainea the **card colurrn** oosition of the 
current syoiool being considered by the scanner. i^Nhen a 

carriage return and linefeed were encountereOf the position 
of the next nonblank character was determinea. If ttie 
position was not *’caro column” six, an '* end-o f - s t a t emen t ” 
token was passed to the parser. The line position cointe^' 
was also used to recognize the end of valia statement in nut 
at “card column” seventy-t^^o. 

c. bemantic Analysis 



As noted creviously, the grammar for the ca'^s 1 



proarari; does not- 


enforce 


the order ana 


t^e t/ce^ 


o ^ 


statements allowed 


in each 


program unit. 


Order cam 


c e 



enforced in the semantics of the orogram by the use of twe 
flags: one flag to determine the tyoe of orogram unit beino 
processed (main procram, suoroutine, function, or block 
data), and a second flan to determine if a particular 
statement is valid cased on the previous statements that 
have been processed. Each statement in the grammar for this 
program has an associated reserved wore. /*nenever a 
reserved word for the statement currently being processed is 
encountered, the flags can be checked to determine if the 
statement order is correct and if that tyoe of statement is 
valid in the orogram unit. 

The use of the ” format incut” token in tne 
grammar reauires the process i no of format statements ir toe 
semantics of the program. In addition, this information 
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must be saved for later use by the oass 2 program in the 
processing of the executable statements. This can oe 
accomolished by either writing the information required to a 
floppy disk file/ or by saving tne information in the 
"scratch pad" area of the control program. bince the number 
of format statements may be large/ the exact implementation 
must be basea on the actual memory available for use in the 
control prooram. 





Ihe general 


express i on 


definition i 


n the F U P T R A 


grammar has 


a direct 


i 


moac t on 


the pass 1 


D r og r an . 


Tne 
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excr<=»ssion 


( c n a rac t 


e r f 


logical/ or 


a r 1 t n m e n t 


1 c ) 


el 1 ow»d 


within each 


state^e^^t 


0 f 


the F 0 K T K A M 


input. 


In 


some cases/ such 


as d 1 r e n s 


i on 



statements/ only integer constant expressions are valicj. 
Integer constant expressions are a special case of the 
arithmetic expression in which only integer constants or 
variables of tyoe integer are allowea. The semantics of tne 
compiler must also process these special expressions and 
provide for their evaluation and use. 

d. Code Generation 

The type of code generation produced by a 
compiler is niqhly dependent on the system in which it is 
implemented. The design decision to produce an intermediate 
lanauage instead of executable machine code was based on t^o 
major considerations. First, the production of an 
intermediate language enhances the t ransoo r t ao i 1 i t y of an 
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eventual system implementation 



FORTRAN 



other 



of FORTRAN to 
microcomputers that suoport PL/M. Secondr the existence of 
an interpreter of Pasic^E IS]^ which translates an 
intermediate language output from the Basic-E compilerf has 
already been successfully imnlemented in the comouter 
laboratory at the Naval Postgraduate School. This 
interpreter is an excellent candidate for modification for 
use with FURIRAN if trie intermediate lanouage orooucec oy 
the FORlRAN comoiler is compatible with the Basic^E 
intermediate language. 



d. Pass ?. bpQqp^rr 



The pass ? program implements the grammar or^^s anted 
in Appenaix o. Tnis proaram processes FORTRAN executable 
statements. Syntactic and semantic analysis^ 3ymt)ol table 
man i DU ) a t 1 on r and parser routines must again ce incluaec in 
the program. This section describes the oesian requirements 
imposed by the FORTRAN gram, mar and adaitional uesign 
considerations necessary for implementation of the orogra^n. 



a . Pa r se r 



The parser/ which controls the execution of the 
pass 2 . program/ can be identical to the parser descrioea in 
the previous section. 



Execution of the parser is terminated after the 
eno statement is parsed. At this point the Program must 
determine if there are ad c^itional orooram units to oe 
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comcilea. Tnis can oe done cy cnec^<ing to see if anytnina 
otner than a soft end-of*file or a rare en d-of-file 
occurs after the ca»"riaoe return end linefeeo fcMo^^inc 
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Tne "read oa 


^ ^ 
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t c < e r. 


i S 


tne 


0 i 


i V a d d ' t i 



tr. at "^ust ce recon n'zeo r y " ^ ^ cass i sca^^'e^ 

cole r’entat ion. 

Tre ocrer® ''Viet ion oet^ee"^ io-=’n*’i*'iers e'^n 
array laentifiers is no longe'“ recucec in the se^^anric 
analysis. -t this coint eM ar ^ avs nav^ neen ceciar^c arn 
the array identifiers ere contacen in t*^e sv^bcl *:a‘^ie ann 
can oe easily recognized. 

tne initialization of tne scanner, tre tc<‘=‘'^s 
previously parsed in tne oass 1 or core n for tne ^cst 

executaole statement -^ust oe recovered from tne ’'scratc^ 
caa". Code for cro vicing tnese tc<ens for analysis anc -.s® 
oy tne scanner -^ost oe included in t'^e crecram oripr to 
obtaining any ne« to<ens for tne fi*st executecle state'^e^t. 
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c 



Semantic Analysis 



As noted previously^ the format specification in 
the format statement must oe hanaled in the se it; antics of trie 
proqram. in aadition# provision must be made for retrieving 
the information that was produced for any format statements 
that were processed Dy the pass 1 program. 

The arammar for pass in^poses adcsitiono) 

reouirements for expression evaluation not necessary in tne 
pass I program. For <=xamole/ one form of tre print 
statement wnich is acceptable to the arammar is 
<exoression>. Th^ expression may either bf* an inteaer 
constant oesignating a statement label/ or a character" 
expression. Thus/ the se'^antics must allow the statement 

laoel to be valid as it is parsed up throuoh the expression 

definition associateo with a print state^^ent. Similar 
requirements exist for the read statement ana complex 
constant definitions. 

d* Code Generation 

Since the pass 2 program performs code 

generation for all FORTRAfJ executable statements/ the 
program may exceed the memory si?e available. If this 

occurs/ consideration Should be given to either restrictina 
the types of statements allowed for use in the FuRfPAM 

implementation or to producing parse actions in pass ? and 
adding a oass 3 program to process these parse actions* Tne 



additional orogram could then generate the intern^ediate 
language oesed on the parse actions/ associated information 
and available symbol table information. 

C. LUAUC.K 

fhe oasic task of the loader program is to process the 
intermediate lanouage modules aenerateo by the compiler for 
the various prooram unitS/ and to produce a ^ero-acoress 
intermediate lanouage module that can oe executed cy the 
i nteroreter. 

The following tvo®3 of information asscciatea .vith each 
intermediate language module are necessary for loader 
implementation: (1) the name of the current module/ (2) a 



list 


o f 


external 


names 


ana 




arences with definitions of 


their 


use 


t ( 3 ) the 


aao ress 


0 f 


the 


first byte in the cooe 


area 


o f 


the current modu 


1 e. 


ana 


the length of the cooe 



area of the module in oytes. Output from the loader should 
be designed to enable further linkage if all external 
references have not yet ceen resolved. 

The actual implementation of a loader was not considered 
part of this thesis project ana is left for future 



consideration 
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iNTtRPRETER 



The function of the interpreter is to execute the zerc- 
adaress intermediate language oroouced by eitner the 
compiler or the loaaer* At this point all external 
references must be resolved in order for the intermediate 
language module to be interpreted, 

. [he desian of an interpreter is aependent on the 
specific machine on ’Aynich the FORTRAfJ lanyuaae is to Ce 
implementea. The run-time monitor used for executing ^ne 
intermediate lanauaoe produced by the casic-E compiler [g] 
13 an example of an interpreter teat has been success'^ullv 
implemented on tne bOnO unaer the tP/V’ ooerating system, 
[he monitor oroviaes a numoer of features that would be 
useful in the interpretation of FORTRAu such as the use of a 
floatina point package (71 to perform arithmetic^ function 
evaluation and conversion operations on 3b bit floating 
point numbers, if the intermediate language generated by 
the hORTRATyj compiler is designed to oe compatiole vvith the 
language produced bv the Basic-E compiler^ the modification 
of this interpreter to accept FORTRAN would Great Iv 
facilitate the implementation o^ FORTRAN on the bObO, 
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CONCLUSIONS 



T he success f u 1 


completion of 


the 


f o r ma 1 F OR T K A 


a r a m. m a r 


demons t r a t es the 


feasibility 


o f 


defining an 


amb i ouou s 


1 anquage / such as 


FORTRAN/ using 


an L A LR ( 1 ) 


g r amma r . 



Amoiquities in tne granr-Tiar can De resolveo by proviaino a 
broader definition for t^e language and comoensatino 
semantic actions by a compiler that imple’T^ents the aramr^ar. 

The FUKTR£*N qrafr^mar ^hicn ^as developea was structured 
to define t e lar<jest possible svntax of tFe i^/o orafr 
proposed American National Standard FORThAri. however/ t^^is 
sFioiJld not prevent a user of this grammar Iron redefining it 
to meet the requirements for implementation on a particular 
machine. 



The use 


o f 


a 


f c r ma 1 1 anauage 


ana 


automatic parser 


generat i on 


me t hoos 


proved extremely 


va 1 uab 1 e in tne 


construction of 


the 


FORTRAN comoiler. 


The 


parser that was 


aval ladle 


for 


use 


in processing 


the 


parse taoles/ when 



combined with syntactic and semantic analyzer routines/ led 
to a modular design and the systematic construction of a 
comoiler rather than an avd hoc tecnniaue. 
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system 


with 1 6h Dy t 
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However/ 


the 
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space 



a 3 



remains a problem. It is recommend ea that cons i aeration oe 
given to the replacement of those rules# especially 
input/outout statements# which coulo be tailorea to tne 
specific machine on which the compiler is implementea. 



It is hoped that the LALr^Cl) fORTHAN 
accompanyino system oesian recommenaa t i ons 
basis for the implementation of FORTRAN on 
system. 
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APPENDIX A 



FUR TRAM grammar SEC HUM OimE 



<Droqram> : := 



1 



<program body> 



<s t at ement > : : 



I 

I 



<orog stmf> <program body> <end state> 

<prog stmt> <end state> 

<orogr‘arr body> <end state> 

<end state> 

<subr stmt> <Drogram hody> <encJ state> 

<subr stmt> <end state> 

<func stmf> <orogram Dod/> <ena sta^e> 

<^unc 3t-nt> <end state> 

<block ca^a stmt> <orogra'^ booy> <er>c stdte> 
<state'nent> 

I <oroqrarri boay> <staternent> 

= <label> <oarrn st^t> <eos> 

I <1abe1> <imDl stmt> <eos> 

! <1abel> <dimen stmt> <eos> 

1 <1abe1> <common stmf> <eos> 

I <label> <equiv str^t> <eos> 

<)abel> <tyoe stm t> <eos> 

<laDel> <external stmt> <eos> 

! <label> <intrinsic st^t> <eos> 

! <label> <save stmt> <eo3> 

1 <1abel> <data stmt> <eos> 

1 <label> <stmtfunc stmt> <^os> 



as 



I 



<1abe1> <entrv stmt> <eos> 



1 <stmt laoel> <format stmt> <eos> 
<end state> <labe1> <exec stmt reservea word> 

! <1abel> <identifier> = 

1 <1abel> <array element> = 

1 <1abel> <substrina name> = 

! <end stmt> 

<exec stmt reserved word> ::= DO 

1 TF 

! ASSIGN 

! GO 

! CUNTTuUt 
: STOP 
: PAUSE 
! CALL 
! PEAD 
! I'J K I T E 
1 PPINT 
! OPEN 
! CLOSE 
! INQUIRE 
! BACKSPACE 
! ENDFILE 
! PEA'IND 
! PETURN 

<end stmt> EnD 

<orog stmt> <1abe1> PROGRAM <iaenti^ier> <ecs> 



<b 1 oc k data s t m t > 



<label> BLOCK DATA <eos> 



I <laOel> BLOCK DATA <identifier> 
<subr stnnt> <label> SUBROUTIfjE <ident:ifier> <eos> 

! <1aOel> SUBKOUTINt <arq list> <eos> 
<func stmt> <labe)> <tunc id> 

! <laoel> <number t/pe> <func io> 

1 <ladel> <char tyoe> <func ia> 

<func iO> FUNCFTGN <identifier> <eos> 

! FUNCTlOrsi <iaenti^ier> ( ) <eos> 

i FUNLTlOi'i <ara list> <eos> 

<pam stTi^> PAKAf/ip. TEK = <constant> 

I <oar^ 5tTit> f <identifier> = <c0PStant 
<imD] stmt> T^PLICIT <itd 1 list> 

I <impl st'T't> f <iTpl list> 

<imD} list> <innol list heao> <letter range> ) 

<imol list head> <number tyoe> ( 

! CHARACFEP ( 

i character ^ <inteaer constant> ( 

1 <imDl list head> <letter range> / 
<1etter ranqe> <icentifier> 

I <identitier> - <ioentifier> 

<dimen stmt> DIMENSION <array dec 1 > 

\ <dirren stmt> / <array aecl> 

<common stmt> COMMON <com^on name> <coiTmon nlist 

! <comrpon stfPt> / <cO)7imon nlist item> 



<eos> 



> 



i t > 



<common name> i • - <emoty> 

I <labe] common r\ame> 

I <doub1e slasH> 

<common nlist item> <iaentifier> 

! <array id> 

! <array aecl> 

<label common narne> / <iaentifier> / 

<equiv stmt> ::= EULliVALtNCE <eauiv nlist> 

! <^quiv stmt> / <ecuiv nlist> 

<eouiv nHst> <eauiv nlist Head> <enuiv nlisC iten-> j 

<equiv nlist heao> ( <ecuiv nlist item> , 

J < p q t j 1 V n i i s t h e a a > 

<eauiv nlist item> / 



<equiv nlist item> <identitier> 

1 <a r r ay i d> 

I <array e 1 ement > 

1 <substrino name> 

<type 5tmt> <numoer type stmt> 

! <char tyoe stmt> 

<number type stmt> <number tyoe> <tvpe item> 

I <numoer type stmt> f <tvpe item> 
<type item> <ioentifier> 

I <array i d> 

I <a r ra y dec 1 > 

<char type stmt> <char tyne> <cHar name> 



1 <char type stmt> 



<c h a r n ame> 
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<char name> ::= <identifier> 

1 <identiMer> ^ <char 1en> 

! <a r ra y aec 1 > 

I <array aec 1 > ^ <char len> 

I <array id> 

I <array id> * <char len> 

<external stmt> ::= EXTERM AL <identifier> 

1 <external s t 'ti t > f <identifier> 
<intrinsic stTtt> Ii>jTRI > J SIC <identifier> 







; < intrinsic Strrit> > 


< 1 den t i 


f 1 e r > 


<save 


3 t fT: t > 


: : = S a V F 










! <save li3t> 






<S8 ve 


1 1 s t > 


S^VF <save ite'n> 










1 <save li3t> r <save ite'Ji> 




<save 


i t e"n> 


<iaentifier> 










! <a r ray i d> 










1 <laoel common name> 






<dat a 


s t mt > 


::= <data list> <data clist 


1 t en^> 


/ 


<da t a 


1 i s t > 


<data head> <data n1ist 


1 t em > 


/ 






I <oata 1ist> <data clist 


i t e m > / 




<da t a 


head> 


; ;= DATA 










! <data heaa> <data nlist 


1 t em > f 




<dat a 


n 1 i s t 


item> ::= <idpntifier> 







<array i d> 

<array element> 
<suostring namp> 
<impHed do list> 
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<data clist item> 



<iaenti fier> 



< i m D 1 i e d do 1 i 
<strrtfunc Stmt 
<entry stmt> S 

< format s t mt > 
<do 1 i s t > : : = 

! < 

<func ref> • i- 

t 

I 

<arq list> 

<arg heaa> : : = 

I 

I 

<a rg el emen t > 

<a r ray nec I > : 

<d i men dec 1 1 i 



s t > 



> ; 



<c ons t an t > 

<intecier constant> * <constant> 

< integer constant> ^ <identifier> 
<identifier> ^ <constant> 
<identifier> ^ <iaentifier> 

= ( <array element> f <do list> ) 

( <imoHea ao list> /. <do list> ) 
<aro list> = <exo> 



! <icentifie^> ( 3 - <exn> 



;= <id9mtifier> 



1 lMTRY <ara Hst> 

1 L N 1 ^ T < 1 a e n t i f 1 e r > ( ) 

f-OrcN'AT <forT0t inout> 

<iaentifier> “ <exp> , <exo> 
identifier> :: <exo> / <exo> / <exp> 

<identifier> ( ) 

<a rq I i s t > 

<a rg head> ) 

<identifier> C <ara element> 

<arq heaa> f <arg element> 

: : = <exD> 
i <ar ray i d> 

: * 

<array id> <dimen decl list> <dimen dec! ) 
s t > : : - ( 

I <dimen decl list> <aimen decl> / 
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<dimen decl> 



<e X p> 



I <exD> : <exD> 

<array elempnt> <array element )ist> <exp> ) 

<aray element 1ist> <array i o> ( 

1 <array element list> <exc> , 
<substrinq name> < i den t i f i e r > ( <substrinq dec 1 > 

! <array element> t <substri nq decl> 
<substring decl> <exp> : <exo> ) 

I <p X D> : ) 

i : < e X D > ) 



' • ) 

I • } 

<exr> <loaica1 terTi> 

I <exp> •UR. <loaical term> 

<1oaicd1 term> ^logical tactor> 

! <locica1 terTi> .Af\lD. <logical tactor> 
<1ogical factor> <logical primary> 

! .NOT. <loaica1 orimarv> 

<1oqical primarv> <cnar exp> 

I <char exD> <re1 op> <cnar exp> 
<Char exp> <arith exp> 

1 <char exp> <ooub)e s)ash> <arith exp> 
<arith exo> <arith term> 

+ <arith term> 

- <arith term> 

<arith exp> t <arith term> 

<arifh exp> - <arith term> 
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<anth term> 



<arirh factor> 



! <arith term> / <arith factor> 
t <arith term> * <arith factor> 

<arith factor> <arith primary> 

I <arith factor> <expon oo> <arith Drimarv> 
<ariCh orimary> <constant^ 

1 <iclentifier> 

I <array e1err'ent> 

! <substrinq name> 

1 <tunc ref> 

1 <pa ren e xp> 

<caren exo> :!= i. <“xc> ) 

<constant> <integer constant> 

! <real constant> 
i <dole ore constant> 

I <1oaical constant> 

! <char constant> 

1 <cofT'plex constant> 

<co.T'plex constant> ::= ( <real constant> / <rea1 conbtcint> ) 
< re I op> : : = . L T . 

I .Lt. 

1 .EQ. 

! ,N£. 

: .GT. 

1 .Gt . 

<}paical constant> .T'^UE. 

; .FALiSE. 
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<nuniDer tvpe> I'NfEGEK 

! REAL 

! DOUBLE PRECISION 
I complex 

: LOGICAL 

<char type> CHARACTER 

! CriARACTEP * <char len> 
<char len> ::= <paren exp> 

! <iriteqer consrant> 

: C * ) 

<label> <emotv> 

: <st.7)t label> 
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APPENDIX B 



FORTRAN GRAMiVAR SECTION T/.O 



< 1 og 

<loQif exec stmt> ; 



<proqrarn> : : ^ <orograrr body> <end stmt> 

<program body> < s f a t ennen t > 

I <Drogranr body> <state^ent> 

<statement> ;:= <1abel> <datd stmt> <eos> 

<label> <logif stmt> 

<laoe1> <do st^t> <eos> 

<1acje1> <entry stmt> <eos> 

<s^mt ^ahel> <format st^t> <eos> 
f exec stPt> 

= <1abe1> <assign stmt> <eos> 

<laDel> <goto strrt> <eos> 

<laoel> <aritnif stmt> <eos> 

<label> <cont1nue stmt> <eos> 

<laDel> <stoD stmt> <eos> 

<label> <pause strr. t> <eos> 

<laoel> <cal1 stmt> <eos> 

<label> <return s t rn t > <eos> 

<label> <read write orint stmt> <eo3> 
<label> <open close inquire strrt> <eos> 
<label> <oaci<sDace end file rewind st^t> 
<eo s> 



<end stmt> END 

<data stmt> <data list> <data clist ite^> / 
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<data list> 



<data nead> <data nlist ite'r> / 



<data heaa> 



I <Oata )ist> <data clist item> » 
: : = DATA 



I <aata Heaa> <data nlist iterr. > , 
<data nlist item> <ia®ntifier> 

! <array i d> 

! <array element> 

I <3UDstring narr,e> 

I <imp)iea GO list> 



<data clist iten> 



<idnnti fier> 



1 <cons t an f > 

I <i''teQer constant> * <ccnstant 
I <incejer constan^> * <iaentiti 
! <identifien> * <constant> 

I <identifier> * <iaentifi“r> 
<imDlied do list> ::= ( <arrav e1ement> t <do list> 

! ( <i'np1ied do 1ist> t <oo list 

<pause stmt> PAUSE 

1 PAUSE <inteaer constant> 

! PAUSE <cnar constant> 

<stop stmt> ::= STOP 

1 STOP <inteaer constant> 

! STOP <cnar constanr> 



<continue stmt> i:= CONTIlViUE 
<return stmt> nFTUP^I 



! return <axD> 

<anthif stmt> lE <paren exo> <aif slaDels> 



SS 



^ r > 
) 

> ) 



<ait slabels> <inteaer constant> ^ <integer constant> # 

<inteoer constant> 

<loaif stmt> ::= IF <oaren exp> <1oqif exec stmt> 

<assiqn stmt> ASSIGN <integer constant> TO <irjentitier> 

1 <identifier> = <exo> 

! <array elennent> = <exp> 

! <suPstring name> = <exp> 

<do st-nt> DO <integer constant> <do list> 

<aoto stmt> GO TO <int 9 aer const;ant> 

I GO 10 <strnt label list> ) <exp> 

! GO 10 <1 den t i f i e r > 

1 0 U TO < 1 d e n t i t i e r > < s t n c I a o e 1 ] i st > J 
<stmt laoel list> ( <intecer constant> 

! < St mt label list> f <integer constant> 

<call stmt> CALL <identifier> 

1 CALL <ara Hst> 

<entry stmt> Et^TRY <identifier> 

I ENTRy <arq list> 
i LNTRY <i(3entifTer> ( ) 

<format st^t> FOR^^AT <forrDat inout> 

<open close inquire stmt> <open close inquire heao> 

<e X o> ) 

I <ooen close inquire Reaa> 

< i o s p e c > ) 

<open close inquire nead> OPEN ( 

1 CLOSE ( 

! INQUIRE ( 
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<open close inauire head> 



< e X n > / 

I <ooen close inauire heaO> 

< i o 3 o e c > » 

<backspace endtile rewina stmt> ::= BACKSPACt <ber list> 

! fii'lDPlLE <ber list> 

1 REWI^JD <ber 1ist> 

<ber list> <exp> 

i ( <exo> , <io spec> ) 

I t < i 0 scec > t <exo> ) 

<reaO write print st"it> <reao print st.'nt> 

! <read write ci list> 

I <read write io list> 

<reaa print stmt> ::= kEAO <exp> 

I READ <arrav ici> 

: read * 

! Print <exp> 

I PRINT <array id> 

: PRINT * 

! <read print stnt> » <io list iten> 

<reao write io list> ::= <read write ci list> <io list ite'"n> 

I <reaci write io list> » 

<io list item> 

<read write ci list> <read w/rite Read> <ci list iterr’> ) 

<read write nead> <reaa paren> 

1 ^iRIIE ( 

I <read write heaa> <ci list iten> , 
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<ci list item> 

1 

1 

1 

1 


< e X p > 

< i 0 spec > 

< a r r a V i d > 


1 

1 


* 



<arrav block ite'n> t:= <array elef"ent> : <array element> 

1 <arrav element > : 

I : <array element> 

<io implied do list> ::= <complex head> <do list> ) 

I <io do list nead> <do list> ) 

<io do list neaa> <complex heaa> <exc> f 



<io list item> 

1 

1 


I ( <arrav id> / 

I ( < array o) oc < > r 

! ( <10 imolied no Mst> / 

I <10 do list heaJ> <io list iter^> / 
= < e X o > 

<a r r av i a> 


1 

1 


<array block it em> 



! <io implied do list> 
<io spec> UMiT = <exp> 



! ERR : 


= <integer constant> 


! REC : 


- < e X p> 


! EidO : 


= <integer constant> 


! FMT = 


= <array id> 


i FMT : 


- <e xp> 


! FMT : 


: ■* 


: FILE 


” < e X o > 



STATUS 



<e xp> 




IT 

I « ^ f # # # a 



BLANK 



< e * D ^ 



! ACCESS = <exp> 

1 FORM = <exr>> 

1 RECL = <exp> 

I MAXREC = <exD> 

1 EXIST = <exp> 

! OPE'MEO = <exD> 

I NUMBER = <pxc> 

! NAMED = <exp> 
i M A M t. = < e X o > 

I ^JEXIREC = <exc> 

<do li5t> <iOentifier> = <exo> r <exr:> 

I <ioentifier> = <exo> , <exo> / <exo> 

<func ref> : <identifier> ( ) 



I <a ro 1 1 s t > 

<arq list> <arg nead> ) 

<arq head> <identifier> ( <ara elemeni'> 

I <arc head> / '^arg e]ennent> 
<arg e]ement> <pxc> 



<a r ray i d> 

* <integer constant> 

★ 



<arrav element> <array element list> <exp> ) 

<aray element list> <array ia> ( 

! <array element list> <exn> / 
<substnnq name> ::= <identifier> C <suEstrinq decl> 

! <arrav element> ( <suDstrinq decl> 
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<subs t r 1 na dec I > 



: = < e X o> 
I <exo> 



<exD> ) 



1 : <exD> ) 

* * 1 

<exo> ;:= <loqica1 term> 

! <exp> .OR. <)oaica1 term> 

<1oaical term> :i- <logical factor> 

! <1ogical terrn> .A NO. <logical factor> 
<logical factor> <loqical orirrary> 

1 . ^ U T . <]oaical ori^arv> 

<loQical Drimarv> <cnar exp> 

! <chdr pxn> <rel od> <c^ar pxp> 

<cnar exo> <arith exp> 

I <cnar exp> <aoubie slash > <aritn exo> 

<aritn exo> <ar ith t e ri)> 

^ <arith ternn> 

• <arith tar^> 

<aritn exp> + <aritn terTi> 

<arith exp> - <ar’ith ternn> 

<arith term> <arith factor> 

I <arith term> / <aritn tact:or> 

1 <arith ^erfT^> ^ <arith tactor> 

<arith factor> <aritn primary> 

I <an’th factor> <expon od> <arith prirrary> 
<arith primary> <constant> 

! <icenti fier> 

! <sr ray el en^en t > 
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<suDstPing name> 



! <func ref> 

I <oaren exp> 

<oaren exp> ( <exc> ) 

<constant> <inteqer constant> 

I <real constant> 

1 <db1e pre constant> 
i <loqical constant> 

1 <cfiar constant> 

1 <CO'T'plex constant> 

<complex constant> ::= <coinn]px head> <a*o> J 
<co'nplex head> ( <exo> / 

<rel op> .LT. 

! .L£. 

! .EQ. 

: .NE. 

; .GT . 

! .GE. 



<logical constant> 



.TRUE. 
I .false. 



<label> li- <empty> 

i <stmt 1abe1> 
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APPtNOIX C 



FORTRAN grammar FOR SIAFEMFNT ORDER 



<program> <orogra^ um’t> 

! <subprogram> 

I <suboroQram> <Drogranr> unit> 

<DPogrann unit> <main orogram> 

! <nrcgranri unit> <suborogram unit> 
<suboroqram> ::= <subcroqran unit> 

1 <subproqraTi> <suDoroqrann unit> 

<suDoroc ran unit> : : ~ <‘^u’^ction 3LJOoroqra'Ti> 

! <suc:)routine subproaram> 

1 <bloc< oata subprcaram> 

<main orograrc\> <proa s t nn t > <main orogram boay> 

1 <main proarann boav> 

<subroutine subprograrr> ll- <suhr s t nn t > <sub program body 

! <subr strit> <rr, ain program bocv 
I <suor stmt> <p]oc< aata boo/> 

I <suor stmt> <end stmt> 

<function subprogram> <func Stmt> <sub program body> 

1 <func stmt> <nnain orograrr body> 

1 <func stmt> <olock aata body> 

! <func stmt> <enq stmt> 

<b]ock data subDrogram> ::= <block data stmr> 

<block data ooay> 



1 <block data stmt> <ena stmt> 



<main program Dody> 



<main^ axec> <end stmt> 



<subproqram boay> <mainl imol> <eno stmt 



<ma 1 ni? 


soec > 


<end 


s t m t > 


< ma 1 n i 


f unc > 


<end 


S t m t > 


< s u b 1 


i mo 1 > 


<encl 


s t m t > 


< sud2 


spec > 


<end 


s t m t > 


<sub3 


f unc > 


< eno 


s t mt > 


< s u b 


e X ec > 


<end 


s f m t > 


< sudS 


return> <end stmt 



<b I oc k 


data 


b 0 d y > c ' = 


<h 1 0 k 1 


i mo 1 > 


<end 


stmt 








! <b 1 okci 


soec > 


< end 


S t m t > 








I <o ! 0 k 3 


aa t a> 


< eno 


s t t > 


<h 1 0 < 1 


• 1 mo I > 


• • 
• • 


= < 1 m p 1 


3 C C > 












1 

1 


< Q a r m 


s t m f > 












1 

1 


<b 1 0 < 1 


i mo 1 > 


< 1 mp 1 


stmt 


> 






1 

1 


<b 1 o k 1 


i mp 1 > 


<pa rm 


Stmt 


> 


<b 1 ok^ 


soec > 


• • 
• • 


= <spec 


s t m t > 












1 

1 


<b 1 o k 1 


i mo 1 > 


< soec 


stmt 


> 






t 

1 


<b 1 o<? 


spec > 


<soec 


stmt 


> 






1 

1 


<b 1 0 K 2 


spec > 


<pa rm 


Stmt 


> 


<b 1 0 k 3 


da t a> 


• • 
• • 


= <da t a 


s t m t > 












» 

1 


<b 1 o < 1 


i mo 1 > 


<da t a 


stmt 


> 






1 

1 


<b 1 0 k 2 


spec > 


< da t a 


Stmt 


> 






1 

1 


<blo<3 


da t a> 


<0a t a 


Stmt 


> 


<m a i n 1 


i mp 1 > 


• • 
• • 


= <format st^ 


t > 










1 


<b 1 Ok 1 


i mo 1 > 


<format st 


m t > 






1 

1 


<ma i n 1 


i mp 1 > 


< i mp 1 


Stmt 


> 



> 



> 



> 
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<mainl imD]> <Darnn stmt> 



<ma i spec > 



<nnain3 func> 



<ma 1 exec> 



< m a i n 1 


1 m D 1 > 


< f ormat stmt 


> 


< 0 1 h e r 


soec 


S t m t > 




<b 1 o k 1 


1 m D 1 > 


< 0 1 her soec 


S t m t > 


<b 1 o < d 


spec > 


<o t he r soec 


s t m t > 


<b] o<2 


spec > 


<format stmt 


> 


< m a i n 1 


i mo 1 > 


<ot he r spec 


s t m t > 


<ma 1 n 1 


1 mo 1 > 


< spec s t m t > 




< nri a i n 2 


soec > 


<other spec 


S t m t > 


<m a 1 n2 


spec > 


<spec stmt> 




< rr a i n ? 


soec > 


<oar^ st'^t> 




< m a 1 n d 


soec > 


<tornnat stmt 


> 


<stfntfunc St 


m t > 




< b 1 0 < 1 


i rn o 1 > 


<strntfunc St 


T t > 


< b ] 0 < ? 


spec > 


<stmtfunc St 


rn t > 


<b 1 OK 3 


da f a> 


<stf'tfunc St 


n t > 


< b 1 0 k 3 


da t a> 


<format stTt 


> 


< rr a i n 1 


1 m p ] > 


<stmtfunc St 


m t > 


< m a i n 1 


1 mo 1 > 


<clata st'^t> 




< T, a 1 n 2 


spec > 


<stmtfunc St 


m t > 


< m a 1 n 2 


soec > 


<aata strt't> 




< m a i n 3 


f unc > 


<st,-ntfunc St 


m t > 


< m a i n 3 


f unc > 


<aata stmt> 




<nia 1 n 3 


f unc > 


<forfriat Stmt 


> 


<exec 


s t m t > 






<b 1 O K 1 


i mo 1 > 


<6'<ec Stmt > 




<b 1 0 < 2 


spec > 


<exec St mt > 
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<sub 1 



< sub£? 



i mp 1 > 



soec > 



! <b 1 o k 3 


d a t a > 


<e X ec 


stmt 


1 < rri a i n 1 


i mp 1 > 


<e X ec 


Stmt 


! < m a i n 2 


spec > 


< e X ec 


Stmt 


1 <rna i n3 


f unc > 


< e X ec 


Stmt 


1 < m a i n ^ 


e X ec > 


<exec 


Stmt 


1 < 71 a i n ^ 


e X ec > 


<da t a 


Stmt 


1 < n a 1 n ^ 


e X ec > 


<format st 


- <en t ry 


s t m t > 






<b 1 ok 1 


1 mp 1 > 


<en t ry 


stmt 


<ma 1 n 1 


1 mp 1 > 


<en t ry 


Stmt 


< sue 1 1 


mnl> stnt> 


< S (J u 1 i 


Tin 1 > < 


parm st'^t> 


< sub 1 i 


3 

0 

V 

A 


format 


stmt 


< 3UD 1 1 


mo ] > <en t ry 


S t m t > 


- <save 


s f m r > 






<b 1 o k i 


1 mp 1 > 


<save 


s t m r > 


<D 1 ok2 


spec > 


<sa ve 


stmt > 


<b 1 ok2 


spec > 


<en t ry 


stmt 


<ma 1 n 1 


i mp 1 > 


< sa ve 


s t m t > 


<m a 1 n 2 


spec > 


<sa ve 


s t m. t > 


<rP3 1 n2 


spec > 


< e n t r V 


stmt 



<sud1 imDl> <other soec stmt> 
<subl irpD]> < soec stmt> 

<suD? spec> <save stmt> 

<suD? spec> <other soec s t ti t > 
<sud 2 spec> <soec s t nn t > 

<sub(? spec> <parn st"it> 
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<sub? spec> <format stmt> 



<sub3 func> 



<sub4 exec> 



< sub 2 


spec > 


<entry stmt-> 




< sub 1 


i ftiD 1 > 


<stmtfunc stmt 


<sub 1 


i mo 1 > 


<data stmt> 




< sub2 


spec > 


<stmtfunc st 


rr t > 


< s ud2 


spec > 


<data stmt> 




<b 1 o k 3 


da t a> 


<entry st""t 


> 


<ma i n3 


f unc > 


<entry stmt 


> 


<sud3 


f unc > 


<stmtfunc st 


rri t > 


< suo 3 


^ unc ^ 


<data stmt> 




< sub 3 


f unc > 


<format- stmt 


> 


< suo 3 


f UPC > 


<0ntry Strr. f> 




< sub 1 


i me 1 > 


<pxec stmt> 




<sud2 


soec > 


<exec stmt> 




< s uo 3 


f unc > 


<exec st^t> 




<'na i n 


e X ec > 


<en try s tf^ t 


> 


< 3 U D 


e X ec > 


<exec st»^t> 




< sub^ 


e X ec > 


<aata stmt> 




< suby 


e X ec > 


<i or^at st'^c 


> 


< suD-y 


e X ec > 


<entry stmt> 





<subb return> 



<return stmt> 



<b] i 


i mp 1 > 


< re t u rn 


s t m t > 


<b 1 ck2 


spec > 


< re t u rn 


stmt> 


<D 1 0^ S 


da t a > 


< r e t u r n 


3 t mt > 


<ma i n 1 


i mp 1 > 


< r e t u rn 


s t m t > 


<ma 1 n ^ 


Spec > 


< r e t u r n 


S t m t > 


< m a i n 3 


f unc > 


< r e t u r n 


s t m t > 



<main4 exec> <re<‘urn st-mt> 



<saec st,Tit> 



<other spec 



<exec stmt> 



1 < S U D 1 


1 m D 1 > 


< re t u rn 


s t m t > 


! < sub? 


spec > 


< r e t u r n 


S t m t > 


! < s u b 3 


f unc > 


< re t u r n 


S t m t > 


! < s U D ^ 


e X ec > 


< re t u rn 


s t m t > 


1 < s u o 5 


re t u rn> 


<return stn^t> 


! <sud5 


r e t u r n> 


<e X ec 


S t fTl t > 


1 < s u b 5 


r e t u r n> 


<aa t a 


S tm t > 


I < suoS 


re t u rn> 


<for.T8t Stnnt> 


! <sud5 


ret u r n > 


<e n t r y 


S t 'T I" > 


<d i ?Tten 


S t t > 








<cofn'^on 


S C T t > 








< eou 1 V 


s t m t > 









1 <type st’Tit> 
s t oit > <external stmt> 

I <intrinsic Stmt> 
<assiqn srmt> 

1 <goto Stint> 

! <arithif st'Tit> 

1 <logif stmt> 

! <do strrt> 

I <continue stnnt> 

! <stoo stmt> 

! <pause s t mt > 

1 <read stiT't> 

I <wnte stmt> 

1 <print stmt> 



J 



bl 









, „ '.■ . 






mm 








'”"vpf>v 












<rewind stmt> 



<backsc8ce stmt> 

< 600 ^^ 1)6 St mt> 

<0oen stmt> 
<close stmt> 

< i nqu 1 re s t m t > 
<ca ] ] St mt> 
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